| 1 |
Jason Stubbs wrote: |
| 2 |
> After thinking about it, incremental "feature creep" does seem like the best |
| 3 |
> way to go at this late stage in 2.0's life. The problem is how to guage what |
| 4 |
> is and what is not more trouble than worth. Perhaps adhering to the kernel's |
| 5 |
> rule of "Separate each logical change into its own patch" would help to ease |
| 6 |
> the possible impact of larger changes? |
| 7 |
|
| 8 |
Probably the best solution. |
| 9 |
|
| 10 |
> Speaking of which, if something does crop up with 2.0.53 while the arch guys |
| 11 |
> are deciding if it's stable, how should that be dealt with in subversion? |
| 12 |
> Continue development under branches/2.0 and, should an issue crop up, `svn cp |
| 13 |
> tags/2.0.53_rc6 tags/2.0.53_rc7` and make any required change directly under |
| 14 |
> the tag? |
| 15 |
|
| 16 |
Never commit to a tag, make a branch (branches are cheap in svn), and if |
| 17 |
the branch is finished make a tag. Btw, anyone object to swap |
| 18 |
branches/2.0 with trunk (seeing that 2.1 is dead)? |
| 19 |
|
| 20 |
> Another "by the way", `svn -v log > ChangeLog` for 2.0.53_rc6. I'm open to |
| 21 |
> anything better if anybody has a good format for autogeneration. The quality |
| 22 |
> of the commit messages themselves isn't really useful though without knowing |
| 23 |
> their context, so this might be a bit of a catch 22.. For 2.0.54, viewsvn |
| 24 |
> should be available so it might be better to just use the tracker bug to |
| 25 |
> manually create a summary of notable changes. |
| 26 |
|
| 27 |
Hmm, so you want to change the ChangeLog into release notes? IMO we |
| 28 |
should have both (a detailed technical ChangeLog and user friendly |
| 29 |
release notes). |
| 30 |
|
| 31 |
Marius |
| 32 |
-- |
| 33 |
gentoo-portage-dev@g.o mailing list |
Archives