| 1 |
On Friday 21 October 2005 19:06, Marius Mauch wrote: |
| 2 |
> Jason Stubbs wrote: |
| 3 |
> > After thinking about it, incremental "feature creep" does seem like the |
| 4 |
> > best way to go at this late stage in 2.0's life. The problem is how to |
| 5 |
> > guage what is and what is not more trouble than worth. Perhaps adhering |
| 6 |
> > to the kernel's rule of "Separate each logical change into its own patch" |
| 7 |
> > would help to ease the possible impact of larger changes? |
| 8 |
> |
| 9 |
> Probably the best solution. |
| 10 |
|
| 11 |
Brian, you agree on this? It'll mean splitting up the cache patch... |
| 12 |
|
| 13 |
> > Speaking of which, if something does crop up with 2.0.53 while the arch |
| 14 |
> > guys are deciding if it's stable, how should that be dealt with in |
| 15 |
> > subversion? Continue development under branches/2.0 and, should an issue |
| 16 |
> > crop up, `svn cp tags/2.0.53_rc6 tags/2.0.53_rc7` and make any required |
| 17 |
> > change directly under the tag? |
| 18 |
> |
| 19 |
> Never commit to a tag, make a branch (branches are cheap in svn), and if |
| 20 |
> the branch is finished make a tag. |
| 21 |
|
| 22 |
The cheapness is exactly why I was questioning. Consider: |
| 23 |
|
| 24 |
# svn cp tags/2.0.53 branches/2.0.53-branch |
| 25 |
# cd branches/2.0.53-branch |
| 26 |
# patch < something-that-needs-fixing-now.patch |
| 27 |
# svn ci |
| 28 |
# cd ../.. |
| 29 |
# svn cp branches/2.0.53-branch tags/2.0.53-r1 |
| 30 |
# svn rm branches/2.0.53-branch |
| 31 |
# svn ci |
| 32 |
|
| 33 |
compared to: |
| 34 |
|
| 35 |
# svn cp tags/2.0.53 tags/2.0.53-r1 |
| 36 |
# cd tags/2.0.53-r1 |
| 37 |
# patch < something-that-needs-fixing-now.patch |
| 38 |
# svn ci |
| 39 |
|
| 40 |
With the way subversion works, I would have thought the end result would be |
| 41 |
identical... |
| 42 |
|
| 43 |
> Btw, anyone object to swap branches/2.0 with trunk (seeing that 2.1 is |
| 44 |
> dead)? |
| 45 |
|
| 46 |
No objections here. |
| 47 |
|
| 48 |
> > Another "by the way", `svn -v log > ChangeLog` for 2.0.53_rc6. I'm open |
| 49 |
> > to anything better if anybody has a good format for autogeneration. The |
| 50 |
> > quality of the commit messages themselves isn't really useful though |
| 51 |
> > without knowing their context, so this might be a bit of a catch 22.. For |
| 52 |
> > 2.0.54, viewsvn should be available so it might be better to just use the |
| 53 |
> > tracker bug to manually create a summary of notable changes. |
| 54 |
> |
| 55 |
> Hmm, so you want to change the ChangeLog into release notes? IMO we |
| 56 |
> should have both (a detailed technical ChangeLog and user friendly |
| 57 |
> release notes). |
| 58 |
|
| 59 |
I'm not much for the ChangeLog at all really. At least not without going over |
| 60 |
what makes a good commit message and setting up some guidelines. I'm |
| 61 |
definitely for any ChangeLog being autogenerated though. |
| 62 |
|
| 63 |
-- |
| 64 |
Jason Stubbs |
| 65 |
-- |
| 66 |
gentoo-portage-dev@g.o mailing list |
Archives